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(57) A virtual network map view of all nodes is pro- 
vided in a network which is representative of VoIP utili- 
zation of the network. As VoIP packets traverse ele- 
nnents of the network, information is stored or logged for 
use by a network management service. Combined with 
knowledge of the physical manifestation of the network, 
the virtual network map is created and used to manage 
the network as it relates to VoIP traffic. Other modeled 
devices such as routers, frame relay access devices 
(FRADs) and switches complete the picture by repre- 
senting the logical virtual connections between nodes. 
A virtual link between communicating ICS devices is 
modeled, managed and configured independent of ac- 
tual multiple and complex real interfaces or links. 
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Description 

Field of the Invention 

[0001] This invention relates generally to the field of 
data networks, and in particular to the nrianagement of 
voice and data traffic over such data networks. 

Copyright Notice/Permission 

[0002] A portion of the disclosure of this patent docu- 
ment contains nnaterial which is subject to copyright pro- 
tection. The copyright owner has no objection to the fac- 
simile reproduction by anyone of the patent document 
or the patent disclosure as it appears in the Patent and 
Trademark Office patent file or records, but otherwise 
reserves all copyright rights whatsoever. The following 
notice applies to the software and data as described be- 
low and in the drawing hereto: Copyright © 1 998, Nortel 
Corporation, All Rights Reserved. 

Background 

[0003] The Internet has provided the ability of users 
to bypass normal long distance telephone charges. This 
is done by converting analog or digital voice signals to 
data packets and using the Internet Protocol (IP), trans- 
ferring the IP packets between callers. At the receiving 
end, each caller decodes the LP packets and converts 
them back to voice signals. Since users normally pay 
an Internet service provider for unlimited access to the 
Internet, there is no additional charge for the transfer of 
data. Using the Internet in such a manner to carry tele- 
phone calls without paying additional tolls is referred to 
as Toll Bypass. 

[0004] The major concern for most customers looking 
at VoIP implementations is guaranteeing the quality and 
reliability of the VoIP call relative to the traditional long 
distance call. The quality of the call is measured in terms 
of clarity of voice. Reliability is defined by the ability to 
make a call at any desired time, and ensuring that calls 
are not dropped in the middle of a conversation. Some 
degradation in quality is acceptable. No degradation in 
reliability is acceptable. 

[0005] The Internet Protocol (IP) is inherently connec- 
tionless. This means that packets are sent into the net- 
work with no confirmation or expectation that the other 
end is listening, able to listen, ready to listen or still lis- 
tening. Also, IP treats all packets equally whether they 
contain information that is time critical or not. Voice 
packets are time critical. If they do not arrive on time, 
the voice is interrupted, or portions are skipped, leading 
to perhaps missed information and poor interaction be- 
tween callers. There are a number of ways to implement 
priorities in an IP network to ensure that voice IP packets 
arrive in a more timely manner. Some priority implemen- 
tations are emerging as standards but it will still be many 
years before the standards are stable and widely de- 



ployed. In the interim, organizations wishing to imple- 
ment VoIP solutions must either accept the problems in- 
herent in an IP networkor must spend considerable time 
and effort implementing the wide variety of priority 
5 schemes available to ensure higher levels of Quality and 
Reliability. 

[0006] Many voice engineers are unfamiliar with IP 
and its fundamentals and would not be in a position to 
move quickly into the arts of engineering and imple- 
70 mentingquality of service parameters. Likewisethedata 
networking experts in most organizations are unfamiliar 
with voice circuit engineering and implementation and 
will be wary of allowing priority access to the I P network 
ahead of data traffic. This presents a great challenge to 
75 those managing voice networks. 

[0007] There is a need to monitor VoIP implementa- 
tions for quality and reliability. There is a need for voice 
engineers and data engineers to work together in imple- 
menting high value solutions for their clients. As VoIP is 
20 an emerging technology and deployment is limited in 
scope and scale there are few ways to solve such prob- 
lems. Many analysts and consultants offer up the caveat 
that the technology works and can be implemented but 
that enterprises can count on experiencing problems as- 
2S sociated with scaling the solution to a large number of 
sites (such as more than 50) and then managing the 
quality and reliability on an ongoing basis. 
[0008] Point solutions to these problems involve 
many solution sets for remote monitoring, traffic analy- 
se? sis, protocol analysis, WAIN (Wide Area Network) link 
optimization, etc. The issue is one of brute force analy- 
sis. Although the tools and standards exist for analyzing 
and reporting on LAN (Local Area Network) and WAN 
utilization and performance, there is a need for a better 
35 way to analyze and report on virtual VoIP networks. 

Summary of the Invention 

[0009] A virtual network map view of all nodes is pro- 

40 vided in a network which is representative of VoIP utili- 
zation of the network. As VoIP packets traverse ele- 
ments of the network, information is stored or logged for 
use by a network management service. Combined with 
knowledge of the physical manifestation of the network, 

45 the virtual network map is created and used to manage 
the network as it relates to VoIP traffic. 
[0010] Layered on top of the virtual network map is a 
least cost routing table. Other modeled devices such as 
routers, frame relay access devices (FRADs) and 

50 switches complete the picture by representing the logi- 
cal virtual connections between nodes. Artificial Intelli- 
gence (Al) capability provided by some existing network 
management systems (NMS) defines a virtual link be- 
tween communicating devices. This means that each 

55 virtual link between devices can be modeled, managed 
and configured independent of the multiple and complex 
number of real interfaces or links that it may be com- 
prised of. 
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[0011] A Management Infornnation Base (MIB) is de- 
fined for eacin element in tine network. Once a MIB is 
defined for each elennent in the network, real and virtual 
associations between elements in the network are 
formed for each valid model. This differs significantly 
from the generic NMS implementation where individual 
elements are modeled and managed but virtual or real 
connections cannot be modeled or managed. 
[0012] A voice engineer or data engineer looking at 
real-time network performance sees the utilization in re- 
al time or trends in the utilization over a particular time 
period. By drilling down into under or over utilized virtual 
connections the engineer can make decisions for opti- 
mizing quality and reliability at the real interface or real 
link layer by viewing and managing the VoIP application 
at the virtual link level. 

Brief Description of the Drawings 

[0013] 

Figure 1 is a block diagram of a physical VoIP net- 
work having multiple elements located in 
different cities and having a network man- 
agement system in accordance with the 
present invention. 

Figure 2 is a flow chart of the progression of a VoIP 
packet through the network of Figure 1 . 

Figure 3 is a block diagram of a data structure cre- 
ated by a trap used to collect information 
related to the progression of a Vol P packet 
at each element in the network. 

Figure 4 is a logical diagram of the steady state view 
of a network. 

Detailed Description 

[0014] In the following detailed description of exem- 
plary embodiments of the invention, reference is made 
to the accompanying drawings which form a part hereof, 
and in which is shown by way of illustration specific ex- 
emplary embodiments in which the invention may be 
practiced. These embodiments are described in suffi- 
cient detail to enable those skilled in the art to practice 
the invention, and it is to be understood that other em- 
bodiments may be utilized and that logical; mechanical, 
electrical and other changes may be made without de- 
parting from the spirit or scope of the present invention. 
The following detailed description is, therefore, not to be 
taken in a limiting sense, and the scope of the present 
invention is defined only by the appended claims. 
[001 5] The detailed description provides a description 
of a distributed network and the path which voice over 
IP (VoIP) packets take in the network during transmis- 
sion of such packets between telephone callers. Detail 
is then provided on how information is collected during 
the transmission of VoIP packets and used together with 
static information to construct logical models of the net- 



work in the context of its use for VoIP, The use of such 
models is then discussed followed by a conclusion 
which states some of the potential benefits and de- 
scribes further alternative embodiments. 

5 [0016] In Figure 1 , several sites are shown as having 
local networks 110, 120, 130, 140 and 150 connected 
through a frame relay network 160. Each of the local 
networks comprises multiple elements such as PBX, 
VoIP Router and FRAD. Each PBX generates a least 

70 cost routing table, a trunk provisioning table, denied call 
logs and dialing plan. The VoIP element comprises a 
call routingtable and dialing plan. The Router comprises 
a routing table, interlace statistics, port statistics and in- 
terface provisioning. Each FRAD further comprises DL- 

75 CI provisioning attributes, port speeds and discard 
rules. Each of these elements and data structures are 
in standard use today in networks throughout the world. 
However, to gain access to information from them re- 
garding performance of the network, they have been 

20 polled independently in the past. 

[0017] In a standards based network environment a 
SNMP (Simple Network Management Protocol) Frame- 
work compliant Network Management System (NMS) 
1 70 compiles a Management Information Base (Ml B) for 

2S each type of element such as routers, hubs, switches, 
PBXs, and KSUs (key system units) that it manages. 
The MIB consists of both standard and enterprise spe- 
cific information elements. The MIB defines an object 
for each attribute, alarm condition, fault or event condi- 

50 tion that can be present on the element that it is written 
for. Compilation of the MIB on the NMS enables the 
NMS to communicate with the element for all aspects of 
remote management that are defined in the MIB. This 
methodology and implementation applies equally to all 

55 SNMP Framework compliant NMSs. 

[0018] Manufacturers of elements (routers, hubs, 
switches, PBXs, KSUs) will often develop a custom ap- 
plication that interacts with the NMS to provide an opti- 
mized view of the element they manufacture. This ena- 

40 bles the manufacturer to focus on the things that are 
unique to their product and let the NMS interpret and 
represent the things that are somewhat generic across 
all elements being managed. It does not, however, pro- 
vide a view of the network itself as it is used to transport 

45 VoIP packets. 

[0019] In Figure 2, a modeling process tracks VoIP 
packet progression through the network. This tracking 
is used to provide information for the formation of a vir- 
tual network model as described in the next section to 

so give the network manager a total view of the VoIP ap- 
plication within the network. At 210 in Figure 2, a PBX 
call router determines that a VoIP call is the best path 
and switches the call to a VoIP trunk. An SNMP Trap is 
sent to the NMS or is logged on the PBX element for 

55 later bulk upload to the NMS. The SNMP Trap creates 
a data structure having data elements shown at 310 in 
Figure 3 that captures information about the element for 
which it is generated. The information may vary from el- 



3 



5 



EP 1 017 200 A2 



6 



ement to element, but is directed toward both alarm con- 
ditions and connections utilized for the call. At 220, the 
VoIP gateway resolves the destination IP Gateway Ad- 
dress based on the called number. The voice traffic is 
packetized accordingly and the header is established 
with the IP Gateway Address for the far-end. The VoIP 
Packet is sent via the LAN Backbone. An SNMP Trap is 
sent to the NMS or is logged on the VoIP element for 
later bulk upload to the NMS. 

[0020] At 230, the VoIP Packet is switched through 
the LAN Backbone to the WAN Gateway (a Router/ 
FRAD/ATM Access device) for the site. The VoIP Packet 
enters the ingress queue of the WAN Gateway. An 
SNMP Trap is sent to the NMS or is logged on the WAN 
Gateway element for later bulk upload to the NMS. At 
240, the Destination IP Address is resolved by the IP 
Router. This is accomplished by looking at Static Route 
Tables and/or RIP Route Tables or OSPF Route Tables. 
The VoIP Packet is priority queued to an egress inter- 
face queue that will begin its path to the far-end. An 
SNMP Trap is sent to the NMS or is logged on the WAN 
Gateway element for later bulk upload to the NMS. 
[0021] At 250, each network element (IP Router, 
Switch, etc.) that handles the VoIP Packet on its route 
to the destination address logs the information pertain- 
ing to the VoIP Packet for later upload or retrieval by the 
NMS. At 260, the VoIP Packet arrives at the destination 
WAN Gateway for the site. The VoIP Packet enters an 
ingress queue and is prioritized for delivery to the VoIP 
Gateway device on site. Pertinent information is logged 
or sent as an SNMP trap to the NMS. 
[0022] At 270; the VoIP Packet travels through the 
LAN Backbone for the site on its way to the VoIP Gate- 
way. Its arrival at the VoIP Gateway is logged for bulk 
upload to the NMS or an SNMP Trap is sent. At 280, the 
VoIP Gateway resolves the destination telephone 
number of the VoIP Packet and converts the packet in- 
formation back to telephony data understood by the 
PBX. The call is then passed to the PBX along with the 
relevant signaling information. The VoIP Gateway and 
the PBX send an SNMP Trap or log an event for later 
bulk upload or retrieval by the NMS. Finally at 290, all 
information regarding VoIP packets is fed into the proc- 
ess model built on the provisioning view as described 
below. It has either been stored, or is delivered in bulk 
at this time. 

[0023] The provisioning view works to locate and build 
the logical associations between PBX's and VoIP Gate- 
ways within the total network. This view is built inde- 
pendent of the underlying data network infrastructure 
and represents the ideal, steady-state view of the VoIP 
network. Dynamic changes to the underlying data net- 
work will occur. The fact remains that the steady state 
view of the virtual VoIP network remains constant and 
is based on the actual paths taken by VoIP packets as 
obtained from the trap data structures. Inspection of a 
particular virtual link in the steady-state view will reveal 
the underlying network information and statistics as 



gathered or reported to the model. The trap data struc- 
ture 310 shows some of the elements and optional ele- 
ments that may be used to build the view. As described 
above, the structure is built at each element that a data 

5 packet passes through. It may include a time stamp, 
packet ID, element ID, various alarm conditions if 
present, and may also include an indication of origin and 
destination of the packet. This information is used in one 
embodiment to help build the virtual network which rep- 

70 resents the paths taken by VoIP packets, and also to 
ensure the integrity of the trap information received. 

Building the Steady-State View 

15 [0024] The model process gathers the following infor- 
mation from the noted elements using the SNMP proto- 
col and the Standard and Enterprise MIBs associated 
with the element of interest: 

20 PBX - least cost routing tables, information pertain- 
ing to E&M and/or VoIP trunks. 
VoIP Gateway- resolution tables for Dialed 
Number (DN) » IP address. Host IP Address, De- 
fault Gateway, QoS (Quality of Service) or RSVP 

25 service implementation details. 

WAN Gateway ~ IP routing tables, Layer 2 Interface 
details, QoS or RSVP service implementation de- 
tails. 

30 Rendering the Virtual VoIP Network Model 

[0025] The information elements gathered above are 
compared to the models defined in the NMS for the el- 
ement in question. The NMS in one embodiment com- 

35 prises the Spectrum Network Manager by Cabletron Inc. 
or other advanced NMS, which comprises an artificial 
intelligence algorithm which is able to create logical as- 
sociations between the PBX elements based on the bulk 
information obtained above. This view is a logical map 

40 of how the PBX elements are connected together for 
Voice Communications and Applications. This map re- 
moves the complexity of the underlying data network 
and its many and diverse elements. 

45 Using the Virtual VoIP Network Model 

[0026] Once the steady-state model has been ren- 
dered, the information gathered in from the trap data 
structures is fed into the model. This information adds 

50 useful detail to the model for making engineering and 
troubleshooting decisions. Some examples include: 
[0027] The PBX at A indicated at 410 is originating 
calls to a PBX at B indicated at 420 over a virtual link 
430 in Figure 4. A router 435 in the link between A and 

55 B is configured with two WAN interfaces. One is terres- 
trial 440 and the other via satellite 450. The satellite in- 
terface does not have the necessary delay parameters 
to support a VoIP packet but the router has not been 
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provisioned to exclude the satellite interface from its 
routing decisions for VoIP packets. This results in re- 
peated failures for VoIP communications between Aand 
B. In the model, the PBX element at location A will indi- 
cate an alarm condition due to repeated communica- 
tions failures (the provisioning model defines default or 
user selectable alarm thresholds for each element). Be- 
cause of the Al and the PBX models the NMS is able to 
segment the alarm condition to the Virtual Link between 
A and B. Furthermore the NMS will breakthe Virtual Link 
down into the two actual links and specify an alarm for 
the Satellite interface on the mid-link router. The tech- 
nician or network engineer can now zero in on the mid- 
link router to initiate a new rule that specifies VoIP Pack- 
ets may only use the terrestrial interface. 
[0028] The Network Engineer has established some 
inter-PBX communications standards and thresholds. 
These parameters are fed into the model with the fol- 
lowing outcomes: 

i) . Voice communications between A and Z have ex- 
ceeded the threshold established for indirect com- 
munications (WAN Gateway to WAN Gateway via 
one or more intermediate WAN Gateways). The 
network engineer provisions a direct Permanent 
Virtual Circuit (PVG) between Aand Z on the under- 
lying network. This improves the quality of the com- 
munications between A & Z and off-loads some re- 
al-time critical traffic from the intermediate node(s). 

ii) . Voice communications from location B to other 
locations on the network has increased beyond the 
pre-established threshold. The network engineer is 
alerted to this trend via trending alarms in the NMS. 
Closer inspection of the Vol P Model reveals that the 
site requires the provision of more Vol P trunks. The 
Model also reveals that the underlying network 
bandwidth must be increased to support these new 
trunks. 

[0029] The NMS comprises a computer program in 
one embodiment, which executes or runs on a personal 
computer, which includes a standard processor and ran- 
dom access memory, and further includes a hard disk 
drive for reading from and writing to a hard disk, and 
may further include a magnetic disk drive for reading 
from and writing to a removable magnetic disk, an opti- 
cal disk drive for reading from and writing to a removable 
optical disk such as a CD-ROM or other optical medium. 
The drives and their associated computer-readable me- 
dia provide nonvolatile storage of computer-readable in- 
structions, data structures, program modules and other 
data used in the NMS. Although the exemplary environ- 
ment described herein employs a hard disk, a remova- 
ble magnetic disk and a removable optical disk, those 
skilled in the art will appreciate that other types of com- 
puter-readable media which can store data accessible 
by a computer may also be used in the exemplary op- 
erating environment. Such media may include magnetic 



8 

cassettes, flash-memory cards, digital versatile disks, 
Bernoulli cartridges, RAMs, ROMs, carrier waves for 
electronic transmission of data and the like. Further, the 
programs may be executed by other than an industry 

5 standard personal computer, such as some common tel- 
ecommunication devices having microprocessors or 
other processing elements therein. 
[0030] Program modules may be stored on computer 
readable media and may include operating systems, 

70 one or more application programs, other program mod- 
ules, and program data. Such programs, of course, 
could be down-loaded to a network elements via the In- 
ternet or equivalent communication network and proto- 
col. 

15 

Conclusion 

[0031] A virtual network map view of all nodes is pro- 
vided in a network which is representative of VoIP utili- 
20 zation of the network. As VoIP packets traverse ele- 
ments of the network, information is stored or logged for 
use by a network management service. Combined with 
knowledge of the physical manifestation of the network, 
the virtual network map is created and used to manage 
25 the network as it relates to VoIP traffic. Virtual links be- 
tween ICS are modeled, managed and configured inde- 
pendent of the multiple and complex number of real in- 
terfaces or links that it may be comprised of 
[0032] A voice engineer or data engineer looking at 
30 real-time network performance can see the utilization in 
real time or trend the utilization over a particular time 
period. By drilling down into under or over utilized virtual 
connections the engineer can make decisions for opti- 
mizing quality and reliability at the real interface or real 
35 link layer by viewing and managing the VoIP application 
at the virtual link level. This application is intended to 
cover any adaptations or variations of the present inven- 
tion. It is manifestly intended that this invention be lim- 
ited only by the claims and equivalents thereof. 



Claims 

1 . A computer implemented method for modeling por- 
45 tions of a data network which handle voice packets, 
the method comprising: 



creating data structures regarding elements in 
the data network involved in transfer of voice 
50 packets when such voice packets are handled 

by the elements; and 

defining logical associations between the ele- 
ments based on the created data structures to 
create a view of a virtual voice network. 

55 

2. The method of claim 1, wherein creating the data 
structures comprises creating an SNMP trap. 



EP 1 017 200 A2 



25 



30 



35 



5 



9 



EP 1 017 200 A2 



10 



3. The method of claim 2, wherein the SNMP trap is 
created at each element involved in the transfer of 
voice packets. 

4. The method of claim 2 or 3, wherein the SNMP trap s 
is either logged for retrieval by, or immediately sent 

to, a network manager. 

5. The method of any preceding claim, wherein the el- 
ements are selected from the group consisting of 
PBX call router, VoIP gateway, WAN gateway, IP 
router, and LAN backbone. 

6. The method of any preceding claim, wherein the 
step of creating data structures includes: ^5 

recording information regarding transfer of 
voice packets at each element in the data net- 
work involved in the transfer of such voice pack- 
ets; and the method further includes: 20 
collecting such recorded information to deter- 
mine logical associations between the ele- 
ments, such logical associations representing 
the virtual voice network. 

25 

7. A computer program element comprising computer 
program code means to make a computer execute 
procedure to perform the method of any preceding 
claim. 

30 

8. The computer program element of claim 7, embod- 
ied on a computer readable medium. 

9. A network for transferring data and voice over Inter- 
net Protocol, the network comprising: 35 

a plurality of communication elements, each el- 
ement collecting information regarding voice 
packets as they pass through the elements; 
a network manager that collects the information 40 
from each of the communication elements; and 
wherein the network manager creates a view of 
a virtual voice network from the collected infor- 
mation which represents the elements involved 
in the transfer of voice packets. 45 

10. The network of claim 9, wherein the information is 
collected at each element by a trap routine. 

11. The network of claim 10, wherein the information so 
collected comprises alarm conditions. 

12. The network of claims 9, 10 or 11, wherein the in- 
formation provides the network manager the ability 

to determine the amount of voice packet traffic at 55 
each element. 

13. Electronic signals representing instructions or 



statements to make a computer execute procedure 
to perform the method steps of any of claims 1 to 6, 
wherein the electronic signals are adapted for trans- 
mission over a communication network. 
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